deployment: add minimal kustomize overlays for deploying plugins #197
Conversation
marquiz
force-pushed
the
devel/plugin-images-kustomize
branch
2 times, most recently
from
1d5f73c to
d2b22b4
Compare
marquiz
force-pushed
the
devel/plugin-images-kustomize
branch
from
d2b22b4 to
b23495b
Compare
Moved to contrib/kustomize |
marquiz
force-pushed
the
devel/plugin-images-kustomize
branch
from
b23495b to
6bdcda1
Compare
marquiz
force-pushed
the
devel/plugin-images-kustomize
branch
from
6bdcda1 to
faf48c0
Compare
|
Updated: added (container) securityContext |
marquiz
force-pushed
the
devel/plugin-images-kustomize
branch
from
faf48c0 to
3cb231f
Compare
|
Update: added pod |
marquiz
force-pushed
the
devel/plugin-images-kustomize
branch
from
3cb231f to
41f1044
Compare
marquiz
force-pushed
the
devel/plugin-images-kustomize
branch
from
41f1044 to
dd1d33d
Compare
|
Updated: indentation of daemonset.yaml's fixed |
Signed-off-by: Markus Lehtonen <markus.lehtonen@intel.com>
marquiz
force-pushed
the
devel/plugin-images-kustomize
branch
from
dd1d33d to
cc9e614
Compare
| containers: | ||
| - name: plugin | ||
| image: plugin:latest | ||
| imagePullPolicy: Always |
There was a problem hiding this comment.
| imagePullPolicy: Always | |
| imagePullPolicy: IfNotPresent |
There was a problem hiding this comment.
IIUC, the default [ck]ustomization updates the daemonset to use the unstable image tag, and I thought that was the reason behind using an Always imagePullPolicy, which would make sense to me (to avoid countless late night WTF?-staring sessions at the terminal when testing).
@marquiz @mikebrow If we change the policy here in the daemonset declaration, can we then also kustomize it to Always in the same file where we change the tag to unstable ?
There was a problem hiding this comment.
Yeah, the idea was exactly that. The unstable is a rolling tag, always following the tip of the main branch. We don't have any "stable" (tagged by version tag) images yet and pull policy Always ensures that you get the latest devel build, not some weeks or months old.
I now dropped the imagePullPolicy field from the daemonset.yaml's alltogether and added a common kustomize component (included in all plugin overlays) that patches the pull policy to Always.
There was a problem hiding this comment.
always image pull policy is good for forcing verification of access to private authentication required registries for pods in a multi-tenant situation...
if not present image pull policy is good for allowing pods to share container images that have already been cached
:latest tag is good for asking to check if there is a newer image on the registry every time
:version tags and SHAs are good for requesting a specific version of an image
There was a problem hiding this comment.
we can discuss on the community call
There was a problem hiding this comment.
kk discussed with klihub just need to mention somewhere in these that this is not for production use .. rather dev testing purposes..
| priorityClassName: system-node-critical | ||
| containers: | ||
| - name: plugin | ||
| image: plugin:latest |
There was a problem hiding this comment.
| image: plugin:latest | |
| image: plugin:latest # image and tag "plugin:latest" are placeholders substituted via config |
| spec: | ||
| priorityClassName: system-node-critical | ||
| containers: | ||
| - name: plugin |
There was a problem hiding this comment.
| - name: plugin | |
| - name: plugin # plugin name "plugin" is a placeholder substituted via config |
marquiz
force-pushed
the
devel/plugin-images-kustomize
branch
3 times, most recently
from
a8d3100 to
47b5d99
Compare
|
Major update: separate overlays for stable and unstable images Define separate overlays for stable (released) and unstable images. Utilizes reusable kustomize components to minimize repetition. The stable image would always point to the latest tagged release and unstable use the latest development build from main. The image-stable will need to be updated just before tagging a release (so that the released version points to the correct image). Usage would be like:
|
Define separate overlays for stable (released) and unstable images. Utilizes reusable kustomize components to minimize repetition. The stable image would always point to the latest tagged release and unstable use the latest development build from main. The image-stable will need to be updated just before tagging a release (so that the released version points to the correct image). Usage would be like: 1. Install the latest release kubectl create -k "https://github.com/containerd/nri/contrib/kustomize/hook-injector" 2. Install a specific release kubectl create -k "https://github.com/containerd/nri/contrib/kustomize/hook-injector?ref=v0.10.0" 3. Install the latest development build: kubectl create -k "https://github.com/containerd/nri/contrib/kustomize/hook-injector/unstable" Signed-off-by: Markus Lehtonen <markus.lehtonen@intel.com>
marquiz
force-pushed
the
devel/plugin-images-kustomize
branch
from
47b5d99 to
be0d68d
Compare
@marquiz I think this would be worth including in the documentation additions in PR (#196), because I suspect it will not be obvious for the average user. |
6 participants
No description provided.